Compiling Integrity Checking into Update Procedures

Integrity checking has been investigated extensively in the field of deductive databases. Methods have been developed to optimise the checking of an update by specialising the constraints for the information that could have been affected by it. The optimisation has been applied to sets of updates resulting from the execution of unspecified update procedures. This paper investigates the compilation of integrity checking into the procedures themselves. The paper introduces a (procedural) update language, and describes how constraints are compiled into procedures expressed in this language. The compilation yields conditions on the original database state that guarantee safety of the update. The paper also shows why compilation into procedures offers important possibilities for optimisation not available in the earlier framework. 1 Introduction Integrity constraint enforcement is important for preventing incorrect data being entered in data and knowledge bases. In databases only quite simple constraints are generally enforced by the system, such as types and functional dependencies. However most applications require more complex constraints. An integrity enforcement technique has been developed which separates the integrity constraints from the update procedures. First proposed in the context of re-lational databases [Nic82] the technique has been extensively researched in the context of deductive databases [SK88; Dec86; LST87; BDM88] and the references in [BMM90]. Under this approach the integrity constraints are expressed as logical statements-effectively yes/no queries-and stored in the knowledge base. The system just checks the constraints that could have been affected by the update, and even then only what has (or could have) changed. We call this specialised integrity checking. It will be described in more detail in the next section. To date integrity specialisation has been applied for updated literals (single inserts and deletes), for sets of updated literals, and for intentional updates (in-serts/deletes satisfying a certain condition). However it is normally assumed that the set of updates is the result of an update procedure which is not visible to the spe-cialiser. Specialisation is applied to the resulting update, not to the update procedure. In this paper we show how to specialise integrity constraints for the update procedures themselves. This yields significant reductions in the amount of checking that has to be done at update time. The reason is that update procedures often perform partial integrity enforcement automatically. For example the procedure for hiring an employee will require that he has a salary which is a real number, and that he belongs to …